home *** CD-ROM | disk | FTP | other *** search
/ Chip 1996 April / CHIP 1996 aprilis (CD06).zip / CHIP_CD06.ISO / hypertxt.arj / 9510 / WINDOS.CD < prev    next >
Text File  |  1996-03-10  |  15KB  |  254 lines

  1.           @VUtazás a 32 bit körül@N
  2.  
  3.           @VwinDOwS 90+5@N
  4.  
  5.               Gyakori vita tárgya volt a Windows 95 megjelenése elôtt,
  6.           hogy  az  DOS-tól   független,  igazi  32   bites  operációs
  7.           rendszer-e  vagy sem?  A témát  a korai  bétaverziók  idején
  8.           Andrew  Schulman  elemezte alaposan  Unathorized  Windows 95
  9.           címû könyvében. Mi arra voltunk kíváncsiak e könyv  alapján,
  10.           hogy mi került a végsô verzióba?
  11.               A  Windows  95 nem  más,  mint egy  DOS  és egy  Windows
  12.           egymáson. A Windows 95  legtöbb eleme megvolt már  a Windows
  13.           3.0-ban és a Windows for Workgroups 3.11-ben (WfW),  mostani
  14.           megjelenésében  inkább  csak  kiforrottabbá  váltak  ezek  a
  15.           komponensek.
  16.               A Microsoft sokszor állította, hogy a Windows 95 immáron
  17.           egy újraírt, integrált, a Windows 3.x-szel ellentétben DOS-t
  18.           nem  igénylô   termék.  E   cikk  keretében   azt  szeretném
  19.           megmutatni, hogy ez nem egészen így van -- viszont ez  semmi
  20.           hátrányt nem jelent.
  21.  
  22.  
  23.           @VMiként indul a rendszer?@N
  24.  
  25.               A  Windows  95 indulásakor  azt  hihetnénk, hogy  amikor
  26.           nincs  AUTOEXEC.BAT  és  CONFIG.SYS,  akkor  a  DOS  nem  is
  27.           töltôdik be. Vagyis az  a file, amit sokáig  WINBOOT.SYS-nek
  28.           hívtak, majd IO.SYS-nek kereszteltek át, behívja a  Windowst
  29.           és ezzel kész.
  30.               Ez egyértelmûen nincs így  -- a Soft-ICE debuggerrel  ez
  31.           szépen megtekinthetô:  ez ugyanis  képes úgy  bootolni, hogy
  32.           közben  a  memóriában  marad.  Töréspontokat  aggatva  a DOS
  33.           file-megnyitás, Extended Open/Create, Find First File,  Exec
  34.           funkciók hívásaira érdekes dolgokat tapasztalhatunk. Az elsô
  35.           az, hogy  ez így  -- mûködik.  Következésképp a  WINBOOT.SYS
  36.           (így  nevezem,  mert  egyértelmûbb,  hogy  mirôl   beszélek)
  37.           mégiscsak   DOS   hívásokat  használ.   Láthatjuk,   hogy  a
  38.           WINBOOT.SYS végrehajtása  elôtt a  boot betöltô  megkíséreli
  39.           megnyitni  a   DRVSPACE.BIN-t  vagy   a  DBLSPACE.BIN-t.   A
  40.           WINBOOT.SYS  betölti  a  HIMEM.SYS-t,  az  IFSHLP.SYS-t,   a
  41.           SETVER.EXE-t. Ezek  ismerôsek, nem?  Valójában nincs  másról
  42.           szó, minthogy automatizálták az eddigi folyamatot. Nem  kell
  43.           kézzel beírni az  AUTOEXEC.BAT végére, hogy  ""WIN", enélkül
  44.           is elindul magától.
  45.  
  46.  
  47.           @VHol ""lakik" az operációs rendszer?@N
  48.  
  49.               Tehát  elindult a  Windows, és  betöltôdik a  VMM32.VxD,
  50.           amiben a Virtual Machine  Manager (VMM) is van.  Valójában a
  51.           VMM az  operációs rendszer  -- és  ez így  van már lassan öt
  52.           éve. Amikor  1990-ben beindult  a Windows  3.0 386  Enhanced
  53.           módja,   már    struktúrájában   igen    hasonló   dolgokkal
  54.           találkoztunk: a Windows  V86 üzemmódba tette  a gépet, és  a
  55.           befutó INT 21h hívások egy részét lekezelte védett módban, a
  56.           többit  továbbadta  a   DOS-nak.  Bizonyos  értelemben   azt
  57.           mondhatjuk, hogy  a DOS  fut a  Windows felett,  vagy inkább
  58.           mellett -- hiszen ugyanaz a szerepe, mint a legtöbb VxD-nek:
  59.           kiszolgál bizonyos hívásokat. Hogy ne jussanak el a  DOS-hoz
  60.           az INT  21h hívások,  hanem a  megfelelô VxD-k  lássák el  a
  61.           feladatot, arról a Hook_V86_Int_Chain gondoskodik. Ezzel egy
  62.           VxD beillesztheti  magát a  VxD-k láncolatába,  és ha késôbb
  63.           kap egy olyan hívást, amit lekezelhet, akkor  visszatéréskor
  64.           jelzi, hogy elintézte ezt a hívást. S mivel a DOSMGR.VxD  az
  65.           elsô a láncban, így ez -- és rajta keresztül a DOS --  kapja
  66.           meg utoljára a hívást,  ha egyáltalán elér odáig.  A Windows
  67.           eddigi fejlôdésének egyik fontos eleme, hogy mely  hívásokat
  68.           kezelnek  VxD-k,  és melyeket  nem.  A WfW  3.11  óta már  a
  69.           file-mûveletekre is van VxD, a Windows 95-ben viszont  ilyen
  70.           értelemben  nincs  újdonság.  (Sôt,  kompatibilitási okokból
  71.           kicsit több hívást ad vissza a DOS-nak, mint a WfW 3.11.)
  72.               A  Windows  386  Enhanced  módja  nem  egy  valós  módú,
  73.           bizonytalan operációs rendszerre  épül, hanem önmagában  egy
  74.           operációs rendszer.  Például, ha  egy DOS  ablakban egy  DOS
  75.           hívás történik, azt nem a DOS kapja meg, hanem a VMM.  Tehát
  76.           tulajdonképpen már évek  óta van egy  32 bites, védett  módú
  77.           operációs rendszerünk,  csak valamiért  ezt nem  tekintettük
  78.           lényegesnek.
  79.               S kinek lenne  jó az, ha  a Windows 95  valóban teljesen
  80.           újra lenne írva? A legtöbb 1.0 verziójú szoftver nem éppen a
  81.           megbízhatóságáról híres. A Windows tényleg át lett írva,  de
  82.           mikor?  A Windows  95 DDK-ban  szerepel például  a  VMM.INC,
  83.           ebben az elsô  említett dátum 1988  március 5, az  alkotónak
  84.           pedig RAL-t jelöli  meg. Ez Ralph  Lipe-ra utal, aki  most a
  85.           Windows 95 vezetô építôje. Ha további file-okat (INT2FAPI.H,
  86.           VPICD.INC, VNETBIOS.ASM, VKD.ASM) nézünk meg, kiderül,  hogy
  87.           a Windowst (nagy  részét bizonyosan) tényleg  újraírták 1988
  88.           és   1990   között   a   Windows   3.0   megjelenéséhez.  De
  89.           hangsúlyozom: ez így is van jól.
  90.               Ha  még   visszaemlékezünk  a   Windows  3.0-ra,   akkor
  91.           emlékezhetünk  arra  a  sok-sok  problémára,  amit  okozott.
  92.           Ilyesmitôl nem  kell tartanunk  a Windows  95-nél, mert  bár
  93.           sok-sok  újdonsága  van,  a lényeges  részeit  már  évek óta
  94.           használjuk. Ezek a részek persze nem hibátlanok, de legalább
  95.           jól ismertek. A Windows 95 újdonságait ugyanis  nagyobbrészt
  96.           a VxD-k szállítják, amik tulajdonképpen csak kiegészítôi  az
  97.           operációs  rendszernek.  (E tulajdonságukat  a  Microsoft is
  98.           beismerte a WINA20.386 VxD kapcsán.)
  99.               Említettem, hogy valójában a VMM az operációs  rendszer.
  100.           Sokan  azt gondolják,  hogy a  KRNL386.EXE is  az a  Windows
  101.           3.1x-ben.  Valójában  ez  csak  egy  alkalmazás,   bármilyen
  102.           program elindulhat, amit KRNL386.EXE-nek nevezünk -- akár  a
  103.           COMMAND.COM is.  Ekkor lesz  egy szép,  védett módú DOS-unk.
  104.           Vagyis  ez  egy ""sima"  DOS  extender. A  Microsoft  is így
  105.           gondolta, kétszer is: egyszer a Microsoft C++ 7.0  bétájában
  106.           egy módosított WIN386.EXE (ez a VMM neve a Win3.1x-ben) volt
  107.           MSDPMI  néven.  Ezt  ugyan  nem  adták  ki,  de  hivatkozást
  108.           találunk  rá még  a WfW  3.11-ben is  (1. kép).  Másrészt  a
  109.           Chicago  (alias  Windows  95) egyik  korai  bétájában  ezt a
  110.           programot DOS386.EXE-nek nevezték el.
  111.  
  112.  
  113.           @VProblémák a DOS ablakban@N
  114.  
  115.               A Windows  alatti DOS-ablakok  problémája abból  adódik,
  116.           hogy teljesítménybeli okok  miatt ezek magas  privilégiummal
  117.           futnak.  Minden operációs  rendszernek alkut  kell kötnie  a
  118.           robusztusság és a teljesítmény között -- egyik példa erre  a
  119.           Windows  DOS-ablaka,  a  másik a  Windows  NT  DOS-ablaka. A
  120.           Windows (akár 3.1x, akár 95) DOS-ablakában elindított
  121.               @KCLI
  122.               @KCIMKE: JMP CIMKE@N
  123.               típusú végtelen ciklus magával rántja a rendszert, de  a
  124.           Windows  NT-ben  nem.  Viszont  a  WinNT  DOS-ablakai   igen
  125.           lassúak. (Mellesleg az OS/2-t is magával rántja ez a trükk.)
  126.               Természetesen   van   más,   rendszerösszeomlást   okozó
  127.           probléma is:  azok az  adatok, amelyek  minden task  számára
  128.           írhatók és olvashatók. Sajnos a Windows 95-ben is sok  ilyen
  129.           van.
  130.  
  131.  
  132.           @VPSP-kövületek@N
  133.  
  134.               Térjünk  vissza  a  Win95  és  a  DOS  kapcsolatára!   A
  135.           Microsoft Developer Network (MSDN) CD-n David Long  ""TSR-ek
  136.           támogatása a Windows 3.1-ben"  cikke mellé jár egy  COUNTDOS
  137.           nevû  program.  Ha  ezt  a  Windows  95  alatt  futtatjuk --
  138.           természetesen a 32 bites lemez- és file-elérést  bekapcsolva
  139.           --,  láthatjuk,  hogy  még mindig  szép  számmal  vannak DOS
  140.           hívások. A DOS kezeli még mindig az idôt és a PSP-ket.
  141.               A PSP-k? Hogyan kerülnek ezek a DOS-kövületek a  Windows
  142.           95-be? Minden tasknak, legyen  az Win16 vagy Win32,  jut egy
  143.           darab.  Ezt  szintén  dokumentálták  a  DDK-ban,  mégpedig a
  144.           THCB.H file-ban.  Itt említenek  egy @KTCB_PMPSPSelector@N  nevû
  145.           mezôt. Ha megnézzük a szelektor által kijelölt címen tanyázó
  146.           adatokat,  akkor  döbbenten meredhetünk  az  INT 20h-ra:  ez
  147.           bizony  tényleg  PSP-t  kezel!  Csak  egy  picit  furcsa:  a
  148.           környezeti  változókra mutató  cím szintén  egy védett  módú
  149.           szelektor,  a  parent PSP-re  viszont  valós módú  címzéssel
  150.           hivatkozik. Ez megteheti, ugyanis ha megnézzük a szelektorok
  151.           LDT bejegyzéseit, akkor láthatjuk,  hogy ezek az 1  Mbyte-os
  152.           határ alatt helyezkednek el.
  153.               Ezek után hogyan  lehet azt mondani,  hogy a Windows  95
  154.           megszakítja  a  kapcsolatait   a  DOS-szal  --   ha  egyszer
  155.           dokumentáltan  szerepel  az  egyik  fô  DOS-struktúra minden
  156.           Windows 95 taskban?
  157.               Érdekes módon nincs minden threadnek külön PSP-je,  csak
  158.           minden tasknak. Sôt, a  ""minden task" kifejezés se  pontos:
  159.           csak  a  rendszer  VM-ben futó  taskok  --  Win16, Win32  --
  160.           váltására használja a kernel a PSP-ket. A külön VM-ben  futó
  161.           DOS-ok  nem kapnak  PSP-t. Ebbôl  következik, és  viszonylag
  162.           egyszerûen  ki is  deríthetô, hogy  a legtöbb  DOS hívás  az
  163.           bizony a Set PSP funkció.
  164.  
  165.  
  166.           @VKi kezeli a file-rendszert?@N
  167.  
  168.               A DOS-szal való  kapcsolattartás másik része  például az
  169.           IFSHLP.SYS. Ha ez nincs  betöltve, akkor nem lesz  32BFA (32
  170.           bites file-elérés).  Ez meglehetôsen  furcsa, hiszen  néhány
  171.           VxD végzi a tényleges munkát.
  172.               Azonban ha a WfW  3.11-bôl kiemeljük az IFSHLP.SYS-t  és
  173.           megkíséreljük ezzel ""megetetni" a Windows 95-öt, akkor  nem
  174.           jutunk messzire -- ez a  verzió nem ismeri például a  hosszú
  175.           file-neveket.  Ez  azt jelzi,  hogy  az IFSHLP  valamiképpen
  176.           mégis  aktív  részese  az  alapvetôen  védett  módban  zajló
  177.           file-kezelésnek.
  178.               Ha   valamilyen  módon   (ez  nem   túl  bonyolult,   de
  179.           ismertetése nagyon  messzire vezetne)  elérjük, hogy  az INT
  180.           21h hívások, amiket általában lekezel az IFSMGR,  eljussanak
  181.           a  DOS-hoz,  akkor  kell  valami,  ami  megakadályozza, hogy
  182.           eljusson a hívás  a tényleges DOS-os  file-kezelô rutinokig.
  183.           Ez  az IFSHLP.SYS:  minden bejövô  hívást megvizsgál,  és  a
  184.           legtöbbet visszadobja  az IFSMGR-nek.  Ezzel megtöri  az INT
  185.           21h láncot, így nem  kerülnek végrehajtásra a lánc  legvégén
  186.           elhelyezkedô DOS-os file-rutinok.
  187.               Azért van  szükség erre  a mechanizmusra,  mert lehetnek
  188.           olyan, DOS  alapú programok,  melyeknek szükségük  van arra,
  189.           hogy lássák ezeket a  file-mûveleteket -- ilyen például  egy
  190.           röptömörítô. Amint láttuk, ezeket a Windows 95 is megkísérli
  191.           betölteni,  tehát  kénytelen   foglalkozni  is  velük.   (És
  192.           lehetséges,  hogy  egy  program --  nem  túl  szabályosan --
  193.           globális TSR-nek telepíti magát a Windows 95 alól,  ilyenkor
  194.           is szükség lehet erre.)
  195.               Hogy mûködött korábban ez az integrált rendszer?  Lássuk
  196.           végül az ""új, integrált rendszer" témakörét. Ez  egyáltalán
  197.           nem új.  Hadd idézzek  a Windows  3.1 README.WRI-jébôl:  ""A
  198.           Microsoft  Windows  és  az MS-DOS  együtt  dolgozik,  ez egy
  199.           integrált rendszer.  Együtt tervezték  és tesztelték  ôket a
  200.           számítógépek széles  skáláján. A  Windows 3.1  futtatása más
  201.           rendszereken váratlan eredményeket vagy gyenge teljesítményt
  202.           okozhat" -- olvasható a ""Running Windows with an  Operating
  203.           System Other Than MS-DOS" szekcióban.
  204.               És valóban  könnyen látható,  hogy az  MS DOS  5 és  6.x
  205.           nagyon is  tud a  Windowsról, és  együttmûködik vele.  Ennek
  206.           legegyszerûbb   bizonyítékai    a   Smartdrive-ban    és   a
  207.           Drivespace/Doublespace programokban  elhelyezkedô VxD-k.  Ha
  208.           kicsit  mögé  akarunk  nézni  a  dolgoknak,  akkor   érdemes
  209.           figyelni, amikor elindul a Windows 3.x. Ezt az INT 2Fh/1605h
  210.           interface  segítségével   jelzi  (broadcast).   Lehet,  hogy
  211.           meglepô,  de nemcsak  a különbözô  segédprogramok, hanem  az
  212.           IO.SYS  és  az  MSDOS.SYS  is  elfogja  ezt  a  jelzést,  és
  213.           intenzíven kommunikálni kezd a Windowszal. Ekkor tudatnak  a
  214.           DOSMGR.VxD-vel olyan adatokat, mint például a gép  azonosító
  215.           címe,  amit  az  taskváltásonként  szépen  átírogat.  (Ehhez
  216.           kapcsolódtak a  DR-DOS 6.0  windowsos problémái,  amiket egy
  217.           módosított DR-DOS 6.0-ban -- és persze a Novell DOS 7-ben --
  218.           már megoldottak.)  Ugyanis az  MS DOS  5.0 és  6.x, amikor a
  219.           Windows  386  Enhanced  módban  fut,  úgy  mûködik,   mintha
  220.           hálózaton  lenne.  Valóban, a  DOS-ablakok  a Windows  alatt
  221.           erôsen hasonlítanak a különálló hálózati gépekre.
  222.               Nemcsak címeket ad át a DOS a Windowsnak, hanem  aktívan
  223.           meg is hívja azt, mégpedig a VxD-k dokumentált ""kiskapuján"
  224.           keresztül.  Az  INT  2Fh/1684h hívás  visszaad  egy  VxD API
  225.           belépési pontot --  ez dokumentált is.  Az viszont már  nem,
  226.           hogy például a DOSMGR.VxD (az elôzô hívásnál BX=15h)  milyen
  227.           API-t nyújt. Viszont  az MS DOS-ban  szerepel ez a  bizonyos
  228.           INT  2Fh/1684h  hívás!  A  2.  képen  a  Compaq  MS  DOS 5.0
  229.           IBMBIO.COM-jából láthatjuk e részletet. Saját  IO.SYS-ünkben
  230.           keressünk rá a hexa B8 84 16 CD 2F-re, hamar rábukkanunk!
  231.               Összefoglalva   mindezeket   visszajutunk   az   eredeti
  232.           feltevéshez:  a  Windows  95  szerkezete  és  DOS-szal  való
  233.           kapcsolata megmaradt a régi, több tízmillió gépen  kipróbált
  234.           megoldásnál -- és ez így nagyon is jó.
  235.  
  236.           @KNégyesi Károly@N
  237.  
  238.  
  239.           @VPár szót a VxD-krôl@N
  240.  
  241.               A VxD-k a DOS .SYS-einek megfelelô 32 bites, védett módú
  242.           Windows programok. Åltalában  32 bites eszközök  vezérlésére
  243.           használják   ezeket    közvetlenül   vagy    a   16    bites
  244.           eszközvezérlôkön keresztül. Valójában a VxD-k alkotják a  32
  245.           bites operációs rendszer legfontosabb részét.
  246.               A VxD-k a SYSTEM.INI [device] szekciójában tölthetôk be,
  247.           a ""*" karakterrel kezdôdôek a VMM részei.
  248.  
  249.           @<9510\WINDOS1.GIF>■■@N  1. kép: Hivatkozás a VMM-re: a WfW 3.11 WIN.COM-jából ollózva...
  250.  
  251.           @<9510\windos1a.gif>■■@N  ...illetve amikor ezt ki is írja
  252.  
  253.           @<9510\WINDOS2.GIF>■■@N  2. kép: Windows-funkciót hív a DOS
  254.